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SLS M&FM Scope 


• Subset of the SLS Vehicle Management (VM) functions 

- Guidance, Navigation, and Control (GN&C) 

- Mission and Fault Management (M&FM) 

• Manages SLS element and subsystem operations implemented in the SLS Flight 
Computer (FC) software 

- Nominal operations for: 

• Management of Core Stage (CS) subsystems (Avionics, MPS, CS TVC) 

• Interaction with the two Boosters for ignition, Booster TVC, and separation 

• Interaction with the four CS Engines for engine start and shutdown 

- Fault management for: 

• Detection and notification of SLS abort conditions, with autosafing where required 

• Notification of Caution and Warning (C&W) events 

• Redundancy Management (RM) to maintain critical functionality 

• Abort Trigger Sensor Data Qualification (SDQ) 

• Nominal and FM teams were separate for Ares I, but have been combined for SLS 

- More efficient design — both functions address vehicle configurations, states & modes 

- Reduced overlap between groups (gray areas of off-nominal) 

- Reduced impact to element and subsystem 

- Better flow of understanding and potential improvements between the functions 

• Current focus is on on-board FM capabilities 

- Trades are being conducted for allocation of functions between on-board and ground-based 

- FM for SLS ground systems being led by KSC and supported by VM/M&FM team 
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SLS FM Development Collaboration 


• Safety and Mission Assurance (S&MA) 

- Define safety and reliability constraints for the system 

- Provide failure assessments (FMEA, Hazards, 
Probabilistic Risk Assessment, Fault Trees, Failure and 
Abort Scenarios) 

- SLS Loss of Mission (LOM) and contribution to Loss 
of Crew (LOC) estimates 

• Systems Engineering and Integration (SE&I) 

- Define SLS FM-related requirements 

— Vehicle Functional Analysis Model (VFAM) 

— Interfacing with MPCV 

- Integrated aborts analysis 

• Elements (Stages, Boosters, Engines, payloads) and 
Subsystems (MPS, RCS, TVC, etc.) 

- Element and subsystem operational scenarios and 
schematics 

- FMEA insight 

- Failure probability data 

- Response assessment support 

• SLS Disciplines 

- Integrated Avionics and Software 

- VM/GN&C 

- Structures and Environments 

- Propulsion 

- Operations 
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SLS FM Development Collaboration 



Multi-Purpose Crew Vehicle (MPCV)/Orion 

- Abort Decision Logic (ADL) interface 

- MPCV/SLS Integrated Aborts analysis 

- Integrated failure definition 

- SLS abort conditions MPCV must detect 

- Required MPCV response capabilities on SLS 

• Retargetting 

• Manual steering 

• Engine shutdown and FTS discretes 

Crew Office - Most vested interest 

- Expertise and response preferences 

- C&W preferences 

- Automatic function inhibit definition 

• Automatic aborts 

• Engine redline shutdowns 
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Tools and Sources for Failure/Fault Identification 


- . 


Goal Tree/Success Tree 

- A top-down, design independent functional decomposition approach for early identification of potential 


monitored failure conditions for 


or redundancy management 


- Identifies critical functions that must be protected 

** J-j \ 

- Precisely defines abort conditions and friggMSjiit terms of state varial 

- Identifies hierarchical relationships between jabort conditions & triggers 

Hazards Analysis — ; 


- Top-down identification of threats to the vehiclg/System, which can lead to failure 

- Require a “control” to mitigate the Inuard through design margins, procedural actions, or automated 

monitoring and response | 
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e Scenario^/Abort Scenarios 
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abort conditions 
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Heritage conditions defined on previous programs 

- Conditions were previously identified or employed for Ares I and shuttle 

- Conditions must be reassessed on SLS because of different configurations, interactions, and failure outcomes 
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Selection of On-board Monito 


For Abort Conditions: 






Calculate probability of occurrence 

- For abort conditions, a 1/100,000 probabilky 
failures and filtering non-credible failifres • 
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Assess detectability 

- Availability of reliable, feasible, affordable tri; 

Determine highest level of failure which absol 
Abort Warning Time (AWT) 
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Selection and Assessment of Triggers 



Identify and assess abort trigger “safety 
net” for qualitative coverage of top- 
level functions 


Then, for each credible abort condition: 

• Identify candidate triggers for each abort 
condition 


- Example: TVC failures may be detected by: 

• Actuator position sensors 

• Loss of turbine speed 

• Loss of hydraulic or pneumatic pressure 

• Failure of TVC avionics 

• Violation of vehicle rate limits 

• Assess False Positive (FP)/False Negative (FN) 
probabilities associated with each trigger 

- Assessment process factors in physics, sensors, 
avionics architecture, sensor data qualification 
logic, and detection algorithms 

- Completing the False Positive/False Negative 
Handbook begun at the end of Ares I to 
document the FP/FN assessment process 

• Assess related Abort Effectiveness (including 
associated AWT) of each trigger {reference the 
following slide ) 
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SLS FM Design, Triggers, and Response 
Effectiveness Assessment 
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SLS FM On-Board System Implementation and Verification 
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Conclusion 





Extensive analysis is needed to determine the right set of FM 
capabilities to provide the most coverage without significantly 
increasing the cost, reliability (FP/FN), aiftl complexity of the 

Strong collaboration w^th j 
support the determi 
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